home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text1001.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  5.5 KB  |  128 lines
  1. RARE has set up a short study on network access to multimedia
  2. information, which I am conducting.  I'm listening to the discussions on
  3. extending HTML and HTTP with great interest. 
  4.  
  5. Talking to some of the potential USERS of multimedia information servers
  6. (MMIS) and looking at their projects, I came up with a list of
  7. requirements.  I know that WWW can do much of this, but not all, and it
  8. seems that this might be a good time to mention some of these
  9. requirements.  There are sections on Hyperlinks, Presentation (this
  10. matches up with discussions on text flowing, inline images etc),
  11. Searching, QoS and Management.  I'd be interested in comments. 
  12.  
  13. HYPERLINKS
  14.  
  15. It is clear that many applications require their users to be able to
  16. navigate through the information base according to relationships
  17. determined by the information provider - in other words, hyperlinks. 
  18.  
  19. Some "hypermedia" systems are in fact simply hypertext, in that they
  20. require the source anchor of a hyperlink to be in a text node.  A true
  21. hypermedia system allows hyperlinks to have their source anchors in
  22. nodes of any media type.  This allows a user to click the mouse on a
  23. component of a diagram or on part of a video sequence to cause one or
  24. more related nodes to be retrieved and displayed. 
  25.  
  26. Some hypermedia systems allow target anchors of a hyperlinks to be
  27. finer-grained than a whole node - eg the target anchor could be a word
  28. or a paragraph within a text document.  It is not clear to me whether
  29. this is a critical requirement.
  30.  
  31. PRESENTATION
  32.  
  33. Related information of different media types must be capable of
  34. synchronised display.  The synchronisation may be in time and/or space. 
  35. For instance, an image may have an associated text caption which should
  36. be retrieved at the same time as the image and displayed adjacent to it,
  37. perhaps in a window which the user can scroll.  A sound clip may have
  38. some associated text (perhaps a translation) which must be displayed in
  39. sync with the sound, eg in an automatically-scrolled window. 
  40.  
  41. SEARCHING
  42.  
  43. Database-type applications require varying degrees of sophistication in
  44. retrieval techniques.  Typically, non-text nodes form the major data of
  45. interest.  Such nodes have associated descriptions, which may be plain
  46. text, or may be structured into fields.  Users need to be able to search
  47. the descriptions, obtain a list of "hits", and select nodes from that
  48. list to display.  Searching requirements vary from simple keyword
  49. searching to full-text indexing (with or without Boolean combinations of
  50. search words), to full SQL-style database retrieval languages.
  51.  
  52. The user must be able to retrieve and display all the information in a
  53. record in a single operation.  (This may involve several separate
  54. retrieval operations "under the hood", but the user should not be aware
  55. of this.)
  56.  
  57. QUALITY OF SERVICE
  58.  
  59. User toleration of delay in computer systems depends on user perception
  60. of the nature of the requested action.  If the user believes that no
  61. computation is required, tolerable delays are of the order of 0.2s.  If
  62. the user believes the action he or she has requested the computer to
  63. perform is "difficult" - for instance a computation of some form - then
  64. a tolerable delay is of the order of 2s.  Users tend to give up waiting
  65. for a response after about 20s.
  66.  
  67. Such user expectations are difficult to meet, particularly for
  68. voluminous multimedia data.  There are several ways of alleviating this
  69. problem, some of which are described below. 
  70.  
  71.  *    Give clues that fetching a particular item might be timeconsuming -
  72.     simply quoting the size may be sufficient. 
  73.  
  74.  *    Display a "progress" indicator while fetching data. 
  75.  
  76.  *    Allow the user to interact with other, previously fetched information
  77.     while waiting for data to be fetched. 
  78.  
  79.  *    Allow several fetches to be performed in parallel. 
  80.  
  81.  *    Pre-fetch information which the client software believes the user
  82.     will wish to see next. 
  83.  
  84.  *    Cache information locally. 
  85.  
  86.  *    Where multiple copies of the same information are held in different
  87.     network locations, fetch the "nearest" copy.  This is (sometimes)
  88.         known as "anycasting". 
  89.  
  90.  *    Offering multiple views of image or video data at different
  91.     resolutions and therefore sizes enable the user to select a balance
  92.     between speed of retrieval and data quality. 
  93.  
  94.  *      Make provision for using isochronous data streams (if available)
  95.         for audio and video.
  96.  
  97. MANAGEMENT
  98.  
  99. In order to support applications involving real-money information
  100. services (eg academic publishing) and learning/assessment applications,
  101. there must be a reliable and secure access control mechanism.  A simple
  102. password is unlikely to suffice - Kerberos authentication procedures are
  103. a possibility. 
  104.  
  105. Users must be able to determine the charge for an item before retrieving
  106. it (assuming that pay-per-item will be a common paradigm - alternatives
  107. such as pay-per-call, pay-per-duration are also possible).  Access
  108. records must be kept by the information server for charging purposes. 
  109.  
  110. Learning applications have similar requirements, except that the purpose
  111. here is not to charge for information retrieved, but to monitor and
  112. perhaps assess a student's progress. 
  113.  
  114. OTHER
  115.  
  116. Another requirement which has escaped from the above list is the ability to
  117. specify in a hypermedia document a mail address, in such a way that the
  118. user can click on it to invoke his/her mailer with the address ready
  119. in the To: field.
  120.  
  121. Chris Adie                                   Phone:  +44 31 650 3363
  122. Edinburgh University Computing Service       Fax:    +44 31 662 4809
  123. University Library, George Square            Email:  C.J.Adie@edinburgh.ac.uk
  124. Edinburgh EH8 9LJ, United Kingdom
  125.  
  126.  
  127.  
  128.